Can i create a mask from a shape (in this case an ellipse) and change background color but keep the mask untouched? This ellipse would have its size changed according to the screen and i would have a function windowResized()

Thanks! :)

it uses ever increasing amounts of memory, not much more to say.

it obviously shouldn't

https://pastebin.com/ZNKADezL turingmachine.pde

https://pastebin.com/isBwGXmD GUI.pde (currently unused)

https://pastebin.com/guddfXsM computation.pde

https://pastebin.com/nms3733V data.pde

if you look in the main file there is a PGraphics called p.

when i use this to animate writing, the memory usage goes skyhigh, eventually chrashing.

i can't use it for any longer than three minutes like this.

The minimum amount of code I could recreate the problem with was this:

var graphics;

function setup() {
    graphics = createGraphics(1000,1000);
}

function draw() {
    graphics.get();
}

This produces the expected result, but uses a ton of memory. Here's the relevant info I could get out of Chrome dev tools: The memory is currently at 1.2 gigs, but I've seen it reach 3 gigs, given enought time. Either way, that's way too much memory.

The saw tooth pattern continues indefinitely, with the teeth progressively growing slightly larger, but always dropping back down to the same height. I also checked out the javascript heap snapshot, but it rarely exceeded 10mb, even during peaks.

Based on this, my current theory is that the Graphics.get() method creates excess detached DOM nodes, which build up until garbage collected. However, I don't know why the spikes get progressively larger, nor do I have any idea as to how to fix it. If this is a known bug, or common mistake, any further information, solutions, or workarounds would be greatly appreciated. Thank you again so much for your help!

Running Processing (3.3) with the default memory allocation allows me to render approximately 3000 frames before running out of memory. I then extended the memory to 8 GB, but the result was no different: 3000 frames later, crash. Now, I know for sure that the only new objects created happen during startup, and when a marble is fired. I realize that it isn't incredibly efficient to generate new marbles every time I need one, but hey. Let the garbage collection do the work, amirite?

Unfortunately, it doesn't seem to like doing that. Even after wholly removing all references to each marble, it appears that they may be still residing in memory. Either that, or I'm doing something else very wrong...

Anyone have ideas as to where this sort of memory build up might be occurring? I certainly make use of a lot of ArrayLists, but again, they are reinstantiated each frame so the garbage collector should be picking them up, no?

[Update 1] I tried to implement a finalize() call in each marble. I'm now hitting 5000 frames, so it's progress - but the memory buildup continues. This time, I actually got an OpenGL exception drawing a box()... so I'm thinking that's where my problems may lay; I'm drawing two boxes per unit plus two tubes from Shapes3D per frame, 88 times for each note of the keyboard. Is that the problem?

[Update 2] I re-ran the sketch on a fresh restart, using ~4 GB RAM out of my 16 total. Still set to 8 GB limit, which it hit pretty rapidly. I was able to render about 6000 frames before it started to freeze, and it continued to eek out a couple of frames a minute. The freezes began at frame 6116, and it continued until 6180, at which all progress halted. I stopped the sketch at this point (it had been nearly 10 minutes of inactivity), but I would expect an exception to be thrown if I had let it run.

[Update 3] [Possible fix] So... bad programming practice, I know, but I added in a explicit System.gc() call every frame. Works beautifully so far - memory has not climbed an inch. Slows down work a lot, so the speed is heavily affected (~8 fps to ~3 fps), but at least this means a stable run. Of course, I assumed it was a memory issue, so we'll see if it gets stuck elsewhere.

[Update 3.1] No, still climbing, just slowly because it takes some much time to run gc(). Not fixed.

[Update 3.2] Running it without marble generation is also slowing down and building up memory use. Perhaps this is an issue with the pushMatrix and popMatrix methods?

[Update 3.3] crashed in event thread due to null java.lang.NullPointerException at processing.mode.java.runner.Runner$2.run(Runner.java:577)

[CLOSED] It was my bad; mistake in my code caused objects to be generated non-stop. Still possible GC issue at hand with Shapes3D library, but my issue is solved.

Below is an example of this. The pauses are garbage collections.

void setup () {
   size (200,400,P2D); 
}

void draw() {

  PShape newCells;
     newCells = createShape();  
       newCells.beginShape(TRIANGLES);

         for (int i = 0; i <  2000; i++) {
                newCells.vertex(random(0,width),random(0,height));
                newCells.vertex(random(0,width),random(0,height));
                newCells.vertex(random(0,width),random(0,height));
         }
       newCells.endShape();   

       shape(newCells, 0,0);
 }

I have looked at the garbage collections in VisualVM and it builds up very quickly and moves memory to Old gen.

The same doesn't happen with immediate mode (no PShape)

My questions are:

1) Is this a bug?

2) Would changing GC options help, if so how do you set this up on mac, I am a total novice with Terminal

Edit: Just to clarify, it is clear this is not the way to use PShape, in the context immediate mode or PShape(Group) is appropriate. But my problem is I need to create the shapes in real time, with thousands of triangle each frames, and then repeat the geometry in a mandala (radial symmetry) form.

Now that that's out of the way let me demonstrate exactly what i'm talking about. I'm using processing 2.2.1 though i doubt it would have much to do with this. Here's the classes I've setup. The problem is explained below.

Level[] l;
void setup(){
  l = new Level[1];
  for(int i = 0; i < l.length; i++){
    l[i] = new Level();
  }//a single level would work instead of an array but this for 
//when it's desirable to add more than one running level at a time
  size(500,500);
}

void draw(){
  background(0);
  for(int i = 0; i < l.length; i++){
    //l[i].run();
  }
}

void mousePressed(){
  l[1].phys.cl.loadMap();//****added just recently to show the problem****//
//if you remove the above than the problem "seems" to go away but it's just
//cause the string isn't being called on again.
}
//below is spread around different files but i doubt it would matter much
//I've gutted out a lot of the unnecessary code.

class Level{  //level contains all game objects as well as a personal physics engine
  public
  abstract class BPActor{}
  //just a bunch of level objects i was testing
  class dummy extends BPActor{}
  class player extends BPActor{}
  abstract class NPC extends BPActor{}
  Physics phys;
  Level(){  //dont let this class have same method names as it's inner classes
    phys = new Physics(this);  //this is the physics engine which has a reference to the level
  }
}

//here is the physics engine class's file
//note that the physics engine has it's own hash table and loads data to it from the "chunk loader" class.

abstract class PhysicsBlueprint{
  public
  Level rl;
  ChunkLoader cl;

  void build(){
    cl.loadMap();
  }
}



class Physics extends PhysicsBlueprint{
  public

  Physics(Level _l){
    rl = _l;
    cl = new ChunkLoader(this);
    build();
  }
}

//the last file is for a chunk loader class.  this is what takes data from files and loads it into the hash table.

class ChunkLoader{
  public
  String lines[];
  Physics phys;

  ChunkLoader(Physics _p){
    phys = _p;
  }
  void loadMap(){
    lines = loadStrings("../list.txt");//use list.txt instead of ../list.txt if you are using a data folder but the list file is outside it
    println("there are " + lines.length + " lines");
    for (int i = 0; i < lines.length; i++) {
      //println(lines[i]);  //disabled due to file being too big to log.
    }
  }
}  //OK THAT'S IT.

//the file i referenced was very large for testing purposes. Maybe the JVM didn't like that. //however i test with a small file shows the exact same results.

First save this code into a sketch and make sure to include a dummy list.txt with a few lines of dummy text into the saved folder. The txt file must have more than one line.

Now here's the problem. If you run this code for about 1 min(resource monitor helps if the file is big enough) and press any key you'll notice a crash with a null pointer exception. And this points directly to the string called "lines" in the ChunkLoader class. This tells me that the garbage collector is indeed responsible for the null pointer. Now to repeat the question. Can i disable the garbage collector in processing or at least have a full proof easy way to get around this. If this could happen to a string what's stopping the gc from wrecking my hash table and game objects? If i can get around this I'll have a decent first game developed with a friend within a month. If anyone helps me solve this problem i'll likely make all game engines/level editors i create with processing open source. Other wise i'll have to go back to c++ and openFrameworks. Apologies for the rambling and am grateful for any help/critique.